Extracting data records from one or more data sources on a client system can be challenging. For example, deploying a data extraction system can be time-consuming, as it requires building customized solutions and scripts for varied client systems and/or data sources. Additionally, any errors or failures during the data extraction process on a client system can affect many downstream systems that rely on the data records that are being extracted. Such errors and failures are more common when using customized solutions and scripts as such custom solutions are more error prone and likely to contain bugs. Additionally, typical data extraction systems, using custom scripts, intermingle business logic with data extraction logic, thereby reducing the integrity and security of the system as business logic may be applied to the data records at the time of data record extraction, and may corrupt or modify the data records. Improvements to existing data extraction techniques are necessary to solve these and other problems.
Furthermore, deployment and/or installation of a software package onto a customer-controlled computing device can be challenging. A customer's information security protocols often prohibit using a physical compact disc (CD), universal serial bus device (USB), or other mobile storage device for installation of software on customer-controlled computing devices. Sending a uniform resource locator (URL) to download the software package via email can be insecure, as the email may be intercepted by malicious actors. Manually typing a URL that is complex can be difficult and is prone to user error. For example, curl commands typically include an HTTP Authorization request header which includes a bearer token that is a 256 character hash. However, any randomized character hash, even those shorter than a 256 character hash, can be difficult to transcribe. For example, a URL that includes a randomized character hash, such “6C7bB6a7B” or “x5777Basdv” can be difficult for a user to type and can be easily mistyped. Likewise, such URLs that include a randomized character hash can be difficult to communicate orally, which may be necessary in a scenario where such a URL must be communicated orally between a vendor's personnel and a customer's information security personnel with access to a customer-controlled computing device. Thus, what is needed is a way to easily and securely deploy software to a customer-controlled computing device.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
While each of the figures illustrates a particular embodiment for purposes of illustrating a clear example, other embodiments may omit, add to, reorder, and/or modify any of the elements shown in the figures.